%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                               %
%                       Legal Notice                            %
%                                                               %
% This document is copyright by Olaf Kirch, okir@monad.swb.de   %
%                                                               %
% For copying conditions, please refer to the file COPYING.	%
%                                                               %
% The author is not liable for any damages, direct or indirect, %
% resulting from the use of information provided in this        %
% document.                                                     %
%                                                               %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% When viewing this document with vi on an 80-columns screen,   %
% do a ':se nonumber' first.                                    %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% START OF CHAPTER                                              %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Introduction to Networking}
\label{intro}

% *  Introduction. Idle chit-chat on networking in
%    general. (Being worked upon)
%
%    *  Different concepts of networking: LANs, store-and-forward
%       networks (UUCP), Internetworking. A rough sketch of address
%       resolution and routing in any of these.
%
%    *  Back To Basics: The OSI reference model; layers. The way
%       it's handled in the ARPAnet: IP-addresses and routing.
%       Datagrams vs. streams. Ports and well-known services.
%       The BSD socket library (incl. AF\_UNIX sockets?).
%       The way UUCP does it.
%
% * TCP/IP networking
%
%    *  IP addresses and routing
%
%    *  The domain name system. More on name servers, resolvers,
%       queries. Resource records in the DNS database.
%
%    *  Example. I would like to construct a 'standard' situation
%       throughout the manual that might serve as a reference 
%       for people on a UUCP network as well as a LAN.

\section{History}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Cavemen and the ARPANET                                       %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.history}
\index{Flintstone, Fred}

The idea of networking is probably as old as telecommunications itself.
Consider people living in the stone age, where drums may have been used
to transmit messages between individuals. Suppose caveman A wants to
invite caveman B for a game of hurling rocks at each other, but they
live too far apart for B to hear A banging his drum. So what are A's
options? He could 1)~walk over to B's place, 2)~get a bigger drum, or
3)~ask C, who lives halfway between them, to forward the message. The
last is called networking.


Of course, we have come a long way from the primitive pursuits and
devices of our forebears. Nowadays, we have computers talk to each other
over vast assemblages of wires, fiber optics, microwaves, and the like,
to make an appointment for saturday's soccer match.\footnote{
 The original spirit of which (see above) still shows on some
 occasions in Europe.
} In the following, we will deal with the means and ways by which this
is accomplished, but leave out the wires, as well as the soccer part.


We will describe two types of networks in this guide: those based on
UUCP, and those based on TCP/IP. These are protocol suites and software
packages that supply means to transport data between two computers.  In
this chapter, we will look at both types of networks, and discuss their
underlying principles.

\index{network}
\index{site}
\index{host}

We define a network as a collection of \emph{hosts} that are able to
communicate with each other, often by relying on the services of a
number of dedicated hosts that relay data between the participants.
Hosts are very often computers, but need not be; one can also think of
X-terminals or intelligent printers as hosts. Small agglomerations of
hosts are also called \emph{sites}.


\index{network!protocols}
\index{protocol}
Communication is impossible without some sort of language or code. In
computer networks, these languages are collectively referred to as
\emph{protocols}. However, you shouldn't think of written protocols
here, but rather of the highly formalized code of behavior observed
when heads of state meet, for instance.  In a very similar fashion,
the protocols used in computer networks are nothing but very strict
rules for the exchange of messages between two or more hosts.



\section{UUCP Networks}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Intro to UUCP networks					%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.uucp}
\index{network!UUCP|see {UUCP}}
\index{UUCP|(}

UUCP is an abbreviation for Unix-to-Unix Copy. It started out as a
package of programs to transfer files over serial lines, schedule those
transfers, and initiate execution of programs on remote sites. It has
undergone major changes since its first implementation in the late
seventies, but is still rather spartan in the services it offers. Its
main application is still in wide-area networks based on dial-up
telephone links.


% UUCP-based networks
% are of the store-and-forward variety, which means that the physical
% links between forwarding hosts are activated at certain intervals only
% (usually several times a day), so that any data has to be stored
% temporarily.

%\footnote{
% In the UUCP world, most sites consist of one host,
% but it might also be a LAN with one computer handling the UUCP link
% to the outside world. Such sites are most often managed in a way to
% appear as a monolithic system to the outside world.
%}

UUCP was first developed by Bell Laboratories in 1977 for communication
between their Unix-development sites. In mid-1978, this network already
connected over 80~sites.  It was running email as an application, as
well as remote printing.  However, the system's central use was in
distributing new software and bugfixes.\footnote{
 Not that the times had changed that much\ldots
} Today, UUCP is not confined to the \unix{} environment anymore. There
are both free and commercial ports available for a variety of platforms,
including AmigaOS, DOS, Atari's TOS, etc.


One of the main disadvantages of UUCP networks is their low bandwidth.
On one hand, telephone equipment places a tight limit on the maximum
transfer rate. On the other hand, UUCP links are rarely permanent
connections; instead, hosts rather dial up each other at regular
intervals. Hence, most of the time it takes a mail message to travel a
UUCP network it sits idly on some host's disk, awaiting the next time a
connection is established.


Despite these limitations, there are still many UUCP networks operating
all over the world, run mainly by hobbyists, which offer private users
network access at reasonable prices.  The main reason for the popularity
of UUCP is that it is dirt cheap compared to having your computer
connected to The Big Internet Cable.  To make your computer a UUCP node,
all you need is a modem, a working UUCP implementation, and another UUCP
node that is willing to feed you mail and news.


\subsection{How to Use UUCP}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.uucp.howto}

The idea behind UUCP is rather simple: as its name indicates, it
basically copies files from one host to another, but it also allows
certain actions to be performed on the remote host.


\index{remote!execution}
Suppose your machine is allowed to access a hypothetical host named
\host{swim}, and have it execute the \prog{lpr} print command for you.
Then you could type the following on your command line to have this
book printed on \host{swim}:\footnote{
 When using \prog{bash}, the GNU Bourne Again Shell, you might have to
 escape the exclamation mark, because it uses it as its history
 character.
}

\begin{tscreen}
 \$ uux -r swim!lpr !netguide.dvi
\end{tscreen}


This makes \prog{uux}, a command from the UUCP suite, schedule a
\emph{job} for \host{swim}. This job consists of the input file,
\file{netguide.dvi}, and the request to feed this file to \prog{lpr}.
The \option{-r} flag tells \prog{uux} not to call the remote system
immediately, but to rather store the job away until a connection
is established at a later occasion. This is called \emph{spooling}.


\index{remote!file access}
Another property of UUCP is that it allows to forward jobs and files
through several hosts, provided they cooperate. Assume that \host{swim}
from the above examples has a UUCP link with \host{groucho}, which
maintains a large archive of \unix{} applications.  To download the file
\file{tripwire-1.0.tar.gz} to your site, you might issue

\begin{tscreen}
 \$ uucp -mr swim!groucho!\~{}/security/tripwire-1.0.tar.gz trip.tgz
\end{tscreen}


\index{UUCP!forwarding}
\index{forwarding!UUCP}
The job created will request \host{swim} to fetch the file from
\host{groucho}, and send it to your site, where UUCP will store it
in \file{trip.tgz} and notify you via mail of the file's arrival.
This will be done in three steps. First, your site sends the job to
\host{swim}. When \host{swim} establishes contact with \host{groucho} the
next time, it downloads the file. The final step is the actual
transfer from \host{swim} to your host.


The most important services provided by UUCP networks these days
are electronic mail and news. We will come back to these later,
so we will give only a brief introduction here.


Electronic mail~-- email for short~-- allows you to exchange
messages with users on remote hosts without actually having to know
how to access these hosts. The task of directing a message from your
site to the destination site is performed entirely by the mail
handling system. In a UUCP environment, mail is usually transported
by executing the \prog{rmail} command on a neighboring host, passing
it the recipient address and the mail message. \prog{rmail} will
then forward the message to another host, and so on, until it reaches
the destination host. We will look at this in detail in
chapter~\ref{mail}.


News may best be described as sort of a distributed bulletin board
system. Most often, this term refers to Usenet News, which is by far the
most widely known news exchange network with an estimated number of
120,000~participating sites.  The origins of Usenet date back to 1979,
when, after the release of UUCP with the new Unix~V7, three graduate
students had the idea of a general information exchange within the Unix
community. They put together some scripts, which became the first netnews
system. In 1980, this network connected \host{duke}, \host{unc}, and
\host{phs}, at two Universities in North Carolina.  Out of this, Usenet
eventually grew. Although it originated as a UUCP-based network, it is no
longer confined to one single type of network.


The basic unit of information is the article, which may be posted to
a hierarchy of newsgroups dedicated to specific topics. Most
sites receive only a selection of all newsgroups, which carry an
average of 60MB worth of articles a day.


In the UUCP world, news is generally sent across a UUCP link by collecting
all articles from the groups requested, and packing them up in a number of
\emph{batches}. These are sent to the receiving site, where they are fed to
the \prog{rnews} command for unpacking and further processing.


Finally, UUCP is also the medium of choice for many dial-up archive sites
which offer public access.  You can usually access them by dialing them up
with UUCP, logging in as a guest user, and download files from a publicly
accessible archive area. These guest accounts often have a login name and
password of \user{uucp}/\user{nuucp} or something similar.

\index{UUCP|)}

\section{TCP/IP Networks}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Intro to TCP/IP networks					%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip}
\index{network!TCP/IP|see {TCP/IP}}
\index{TCP/IP|(}
\index{Local Area Network|see {LAN}}
\index{LAN}

Although UUCP may be a reasonable choice for low-cost dial-up network
links, there are many situations in which its store-and-forward
technique proves too inflexible, for example in Local Area Networks
(LANs).  These are usually made up of a small number of machines located
in the same building, or even on the same floor, that are interconnected
to provide a homogeneous working environment.  Typically, you would want
to share files between these hosts, or run distributed applications on
different machines.


\index{network!packet-switched}
These tasks require a completely different approach to networking.
Instead of forwarding entire files along with a job description, all
data is broken up in smaller chunks (packets), which are forwarded
immediately to the destination host, where they are reassembled.  This
type of network is called a \emph{packet-switched} network.  Among other
things, this allows to run interactive applications over the network.
The cost of this is, of course, a greatly increased complexity in
software.


The solution that \unix{} system~--- and many non-\unix{} sites~--- have
adopted is known as TCP/IP.  In this section, we will have a look at its
underlying concepts.



\subsection{Introduction to TCP/IP-Networks}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.intro}
\index{ARPANET}

TCP/IP traces its origins to a research project funded by the United
States DARPA (Defense Advanced Research Projects Agency) in 1969. This
was an experimental network, the ARPANET, which was converted into an
operational one in 1975, after it had proven to be a success.


\index{network!Internet}
\index{Internet}
In 1983, the new protocol suite TCP/IP was adopted as a standard, and
all hosts on the network were required to use it.  When ARPANET finally
grew into the Internet (with ARPANET itself passing out of existence in
1990), the use of TCP/IP had spread to networks beyond the Internet
itself. Most notable are \unix{} local area networks, but in the advent
of fast digital telephone equipment, such as ISDN, it also has a
promising future as a transport for dial-up networks.


\index{Marx, Groucho}
\index{Groucho Marx University}
\index{Kempen, Fred van}
For something concrete to look at as we discuss TCP/IP throughout the
following sections, we will consider Groucho Marx University (GMU),
situated somewhere in Fredland, as an example.  Most departments run
their own local area networks, while some share one, and others run
several of them. They are all interconnected, and are hooked to the
Internet through a single high-speed link.


\index{remote!login}
Suppose your \linux{} box is connected to a LAN of \unix{} hosts at the
Mathematics Department, and its name is \host{erdos}. To access a host at
the Physics Department, say \host{quark}, you enter the following
command:


\begin{tscreen}
\begin{verbatim}
$ rlogin quark.physics
Welcome to the Physics Department at GMU
(ttyq2) login:
\end{verbatim}
\end{tscreen}


At the prompt, you enter your login name, say \user{andres}, and
your password. You are then given a shell on \host{quark}, to which
you can type as if you were sitting at the system's console. After
you exit the shell, you are returned to your own machine's prompt.
You have just used one of the instantaneous, interactive applications
that TCP/IP provides: remote login.


\index{remote!X11 session}
While being logged into \host{quark}, you might also want to run an
X11-based application, like a function plotting program, or a PostScript
previewer. To tell this application that you want to have its windows
displayed on your host's screen, you have to set the \keyword{DISPLAY}
environment variable:


\begin{tscreen}
\${} export DISPLAY=erdos.maths:0.0
\end{tscreen}


If you now start your application, it will contact your X server
instead of \host{quark}'s, and display all its windows on your screen.
Of course, this requires that you have X11 runnning on \host{erdos}.
The point here is that TCP/IP allows \host{quark} and \host{erdos}
to send X11 packets back and forth to give you the illusion that
you're on a single system. The network is almost transparent here.


Another very important application in TCP/IP networks is NFS, which
stands for \emph{Network File System}. It is another form of making the
network transparent, because it basically allows you to mount directory
hierarchies from other hosts, so that they appear like local file
systems. For example, all users' home directories can be on a central
server machine, from which all other hosts on the LAN mount the
directory. The effect of this is that users can log into any machine,
and find themselves in the same home directory.  Similarly, it is
possible to install applications that require large amounts of disk
space (such as \TeX) on only one machine, and export these directories
to other machines.  We will come back to NFS in chapter~\ref{nfs}.


Of course, these are only examples of what you can do over TCP/IP
networks. The possibilities are almost limitless.


We will now have a closer look at the way TCP/IP works. You will need
this to understand how and why you have to configure your machine.  We
will start by examining the hardware, and slowly work our way up.


\subsection{Ethernets}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.history}
\index{protocol!Ethernet}
\index{Ethernet|(}

The type of hardware most widely used throughout LANs is what is
commonly known as \emph{Ethernet}.  It consists of a single cable with
hosts being attached to it through connectors, taps or transceivers.
Simple Ethernets are quite inexpensive to install, which, together with
a net transfer rate of 10 Megabits per second accounts for much of its
popularity.


\index{Ethernet!thin}
\index{thinnet}
\index{BNC connector}
Ethernets come in three flavors, called \emph{thick} and \emph{thin},
respectively, and \emph{twisted pair}.  Thin and thick Ethernet each use
a coaxial cable, differing in width and the way you may attach a host to
this cable. Thin Ethernet uses a T-shaped ``BNC'' connector, which you
insert into the cable, and twist onto a plug on the back of your
computer.  Thick Ethernet requires that you drill a small hole into the
cable, and attach a transceiver using a ``vampire tap''. One or more
hosts can then be connected to the transceiver.  Thin and thick Ethernet
cable may run for a maximum of 200 and 500~meters, respectively, and are
therefore also called 10base-2 and 10base-5.  Twisted pair uses a cable
made of two copper wires which is also found in ordinary telephone
installations, but usually requires additional hardware. It is also
known as 10base-T.


Although adding a host to a thick Ethernet is a little hairy, it does not
bring down the network. To add a host to a thinnet installation, you have
to disrupt network service for at least a few minutes because you have to
cut the cable to insert the connector.


Most people prefer thin Ethernet, because it is very cheap: PC cards come
for as little as US\$~50, and cable is in the range of a few cent per
meter. However, for large-scale installations, thick Ethernet is more
appropriate. For example, the Ethernet at GMU's Mathematics Department uses
thick Ethernet, so traffic will not be disrupted each time a host is added
to the network.


One of the drawbacks of Ethernet technology is its limited cable length,
which precludes any use of it other than for LANs. However, several
Ethernet segments may be linked to each other using repeaters, bridges or
routers. Repeaters simply copy the signals between two or more segments, so
that all segments together will act as if it was one Ethernet.  % Due to
timing requirements, there may not be more than four repeaters % between
any two hosts on the network.  Bridges and Routers are more sophisticated.
They analyze incoming data and forward it only when the recipient host is
not on the local Ethernet.


\index{Ethernet!address}
\index{address!Ethernet}
Ethernet works like a bus system, where a host may send packets (or
\emph{frames}) of up to 1500 bytes to another host on the same Ethernet.
A host is addressed by a six-byte address hardcoded into the firmware of
its Ethernet board. These addresses are usually written as a sequence of
two-digit hex numbers separated by colons, as in \host{aa:bb:cc:dd:ee:ff}.


\index{Ethernet!collision}
\index{collision, Ethernet}
A frame sent by one station is seen by all attached stations, but only
the destination host actually picks it up and processes it.  If two
stations try to send at the same time, a \emph{collision} occurs, which
is resolved by the two stations aborting the send, and reattempting it a
few moments later.

\index{Ethernet|)}

\subsection{Other Types of Hardware}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.other-hardware}
\index{FDDI}

In larger installations, such as Groucho Marx University,
Ethernet is usually not the only type of equipment used.
At Groucho Marx University, each department's LAN is linked
to the campus backbone, which is a fiber optics cable running
FDDI (\emph{Fiber Distributed Data Interface}). FDDI uses an
entirely different approach to transmitting data, which basically
involves sending around a number of \emph{tokens}, with a station only
being allowed to send a frame if it captures a token. The main advantage
of FDDI is a speed of up to 100~Mbps, and a maximum cable length of
up to 200~km.


\index{Packet Assembler/Disassembler}
\index{protocol!X.25}
\index{PAD}
\index{X.25}
For long-distance network links, a different type of equipment is
frequently used, which is based on a standard named X.25. Many so-called
Public Data Networks, like Tymnet in the U.S., or Datex-P in Germany,
offer this service. X.25 requires special hardware, namely a Packet
Assembler/Disassembler or \emph{PAD}.  X.25 defines a set of networking
protocols of its own right, but is nevertheless frequently used to
connect networks running TCP/IP and other protocols. Since IP packets
cannot simply be mapped onto X.25 (and vice versa), they are simply
encapsulated in X.25 packets and sent over the network.


\index{protocol!AX.25}
\index{amateur radio}
\index{ham radio}
\index{AX.25}
Frequently, radio amateurs use their equipment to network their
computers; this is called \emph{packet radio} or \emph{ham radio}. The
protocol used by ham radios is called AX.25, which was derived from
X.25.


Other techniques involve using slow but cheap serial lines for
dial-up access. These require yet another protocol for transmission
of packets, such as SLIP or PPP, which will be described below.


\subsection{The Internet Protocol}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.ip}
\index{protocol!IP|see {IP}}
\index{Internet Protocol|see {IP}}
\index{IP|(}
\index{routing!IP datagrams|see {IP, routing}}

Of course, you wouldn't want your networking to be limited to one
Ethernet. Ideally, you would want to be able to use a network regardless
of what hardware it runs on and how many subunits it is made up of. For
example, in larger installations such as Groucho Marx University, you
usually have a number of separate Ethernets that have to be connected in
some way. At GMU, the maths department runs two Ethernets: one network
of fast machines for professors and graduates, and another one with slow
machines for students. Both are linked to the FDDI campus backbone.


\index{forwarding!IP}
\index{IP!forwarding}
\index{IP!gateway}
\index{gateway}
This connection is handled by a dedicated host, a so-called \emph{gateway},
which handles incoming and outgoing packets by copying them between the two
Ethernets and the fiber optics cable.  For example, if you are at the Maths
Department, and want to access \host{quark} on the Physics Deparment's LAN
from your \linux{} box, the networking software cannot send packets to
\host{quark} directly, because it is not on the same Ethernet. Therefore,
it has to rely on the gateway to act as a forwarder. The gateway (name it
\host{sophus}) then forwards these packets to its peer gateway \host{niels}
at the Physics Department, using the backbone, with \host{niels} delivering
it to the destination machine. Data flow between \host{erdos} and
\host{quark} is shown in figure~\ref{intro.fig.ip-flow} (With apologies to
Guy L. Steele).


\begin{figure}[htbp]
 \iftex
  \ifps
   \begin{center}
    \mbox{\epsffile{figures/ip-flow.epsf}}
   \end{center}
  \else
   \begin{center}
    \input{ip-flow.eepic}
   \end{center}
  \fi
 \else
 \fi
 \caption{
  \label{intro.fig.ip-flow}
  The three steps of sending a datagram from \host{erdos}
  to \host{quark}.
 }
\end{figure}


\index{IP!routing}
This scheme of directing data to a remote host is called \emph{routing},
and packets are often referred to as \emph{datagrams} in this context.
To facilitate things, datagram exchange is governed by a single protocol
that is independent of the hardware used: IP, or \emph{Internet
Protocol}.  In chapter~\ref{tcpip}, we will cover IP and the issues of
routing in greater detail.


\index{internetworking}
\index{network!interconnecting|see {internetworking}}
\index{Internet!vs. internetworking}
The main benefit of IP is that it turns physically dissimilar
networks into one apparently homogeneous network. This is called
internetworking, and the resulting ``meta-network'' is called
an \emph{internet}. Note the subtle difference between \emph{an}
internet and \emph{the} Internet here. The latter is the official
name of one particular global internet.


\index{address!IP}
\index{IP!address}
\index{dotted quad}
Of course, IP also requires a hardware-independent addressing scheme.  This
is achieved by assigning each host a unique 32-bit number, called the
\emph{IP~address}. An IP~address is usually written as four decimal numbers,
one for each 8-bit portion, separated by dots. For example, \host{quark}
might have an IP~address of \host{0x954C0C04}, which would be written as
\host{149.76.12.4}.  This format is also called \emph{dotted quad} notation.


\index{IP!address vs. hostname}
\index{Ethernet!address vs. IP address}
You will notice that we now have three different types of addresses: first
there is the host's name, like \host{quark}, then there are IP~addresses,
and finally, there are hardware addresses, like the 6-byte Ethernet
address. All these somehow have to match, so that when you type
\prog{rlogin quark}, the networking software can be given \host{quark}'s
IP~address; and when IP delivers any data to the Physics Department's
Ethernet, it somehow has to find out what Ethernet address corresponds to
the IP~address.  Which is rather confusing.


We will not go into this here, and deal with it in chapter~\ref{tcpip}
instead. For now, it's enough to remember that these steps of finding
addresses are called \emph{hostname resolution}, for mapping host names onto
IP~addresses, and \emph{address resolution}, for mapping the latter to
hardware addresses.


\subsection{IP over Serial Lines}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.slip}
\index{protocol!CSLIP}
\index{protocol!SLIP}
\index{protocol!PPP}
\index{telephone, sending data over}
\index{serial line IP|see {SLIP}}
\index{Compressed Serial Line IP|see {CSLIP}}
\index{serial line IP|see {PPP}}
\index{Point-to-Point Protocol|see {PPP}}
\index{SLIP}
\index{CSLIP}
\index{PPP}

On serial lines, a ``de facto'' standard known as SLIP or 
\emph{Serial Line IP} is frequently used.
A modification of SLIP is known as CSLIP, or \emph{compressed SLIP},
and performs compression of IP~headers to make better use of the
relatively low bandwidth provided by serial links.\footnote{
  SLIP is described in RFC~1055. The header compression CSLIP is based
  in is described in RFC~1144.
} A different serial protocol is PPP, or \emph{Point-to-Point Protocol}.
PPP has many more features than SLIP, including a link negotiation
phase. Its main advantage over SLIP is, however, that it isn't
limited to transporting IP~datagrams, but that it was designed to
allow for any type of datagrams to be transmitted.


\index{IP|)}

\subsection{The Transmission Control Protocol}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.tcp}
\index{Transmission Control Protocol|see {TCP}}
\index{protocol!TCP}
\index{TCP|(}

Now, of course, sending datagrams from one host to another is not the
whole story. If you log into \host{quark}, you want to have a reliable
connection between your \prog{rlogin} process on \host{erdos} and the
shell process on \host{quark}. Thus, the information sent to and fro must
be split up into packets by the sender, and reassembled into a character
stream by the receiver. Trivial as it seems, this involves a number of
hairy tasks.


A very important thing to know about IP is that, by intent, it is not
reliable. Assume that ten people on your Ethernet started downloading the
latest release of XFree86 from GMU's FTP server. The amount of traffic
generated by this might be too much for the gateway to handle, because it's
too slow, and it's tight on memory. Now if you happen to send a packet to
\host{quark}, \host{sophus} might just be out of buffer space for a moment
and therefore unable to forward it.  IP solves this problem by simply
discarding it. The packet is irrevocably lost.  It is therefore the
responsibility of the communicating hosts to check the integrity and
completeness of the data, and retransmit it in case of an error.


This is performed by yet another protocol, TCP, or \emph{Transmission
Control Protocol}, which builds a reliable service on top of IP.  The
essential property of TCP is that it uses IP to give you the illusion
of a simple connection between the two processes on your host and the
remote machine, so that you don't have to care about how and along
which route your data actually travels.  A TCP connection works
essentially like a two-way pipe that both processes may write to and
read from. Think of it as a telephone conversation.


\index{network!connections|see {network, port}}
\index{port|see {network, port}}
\index{network!port}
TCP identifies the end points of such a connection by the
IP~addresses of the two hosts involved, and the number of a
so-called \emph{port} on each host. Ports may be viewed as
attachment points for network connections. If we are to strain the
telephone example a little more, one might compare IP~addresses
to area codes (numbers map to cities), and port numbers to local
codes (numbers map to individual people's telephones).


\index{remote!login}
In the \prog{rlogin} example, the client application (\prog{rlogin})
opens a port on \host{erdos}, and connects to port 513 on
\host{quark}, which the \prog{rlogind} server is known to listen to.
This establishes a TCP connection. Using this connection,
\prog{rlogind} performs the authorization procedure, and then spawns
the shell. The shell's standard input and output are redirected to
the TCP connection, so that anything you type to \prog{rlogin}
on your machine will be passed through the TCP stream and be
given to the shell as standard input.


\index{TCP|)}


\subsection{The User Datagram Protocol}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.udp}
\index{User Datagram Protocol|see {UDP}}
\index{protocol!UDP}
\index{UDP|(}

Of course, TCP isn't the only user protocol in TCP/IP networking.
Although suitable for applications like \prog{rlogin}, the overhead
involved is prohibitve for applications like NFS.  Instead, it uses a
sibling protocol of TCP called UDP, or \emph{User Datagram Protocol}.
Just like TCP, UDP also allows an application to contact a service on a
certain port on the remote machine, but it doesn't establish a
connection for this. Instead, you may use it to send single packets to
the destination service~-- hence its name.


Assume you have mounted the \TeX{} directory hierarchy from the
department's central NFS server, \file{galois}, and you want to view a
document describing how to use \LaTeX{}. You start your editor, who
first reads in the entire file. However, it would take too long to
establish a TCP connection with \file{galois}, send the file, and release
it again. Instead, a request is made to \file{galois}, who sends the file
in a couple of UDP packets, which is much faster.  However, UDP was not
made to deal with packet loss or corruption.  It is up to the
application~-- NFS in this case~-- to take care of this.


\index{UDP|)}

\subsection{More on Ports}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.ports}
\index{network!services|see {port}}
\index{services}
\index{network!port|(}

Ports may be viewed as attachment points for network connections.  If an
application wants to offer a certain service, it attaches itself to a
port and waits for clients (this is also called \emph{listening} on the
port).  A client that wants to use this service allocates a port on its
local host, and connects to the server's port on the remote host.


\index{port!numbers}
\index{network!port numbers}
An important property of ports is that once a connection has been
established between the client and the server, another copy of the server
may attach to the server port and listen for more clients.  This permits,
for instance, several concurrent remote logins to the same host, all using
the same port 513. TCP is able to tell these connections from each other,
because they all come from different ports or hosts. For example, if you
twice log into \host{quark} from \host{erdos}, then the first \prog{rlogin}
client will use the local port 1023, and the second one will use port 1022.
Both however, will connect to the same port 513 on \host{quark}.


\index{services!well-known}
\index{services!and port numbers}
This example shows the use of ports as rendezvous points, where
a client contacts a specific port to obtain a specific service.
In order for a client to know the proper port number, an agreement has
to be reached between the administrators of both systems on the
assignment of these numbers. For services that are widely used,
such as \prog{rlogin}, these numbers have to be administered
centrally. This is done by the IETF (or \emph{Internet Engineering
Task Force}), which regularly releases an RFC titled \emph{Assigned
Numbers}. It describes, among other things, the port numbers assigned
to \emph{well-known services}. \linux{} uses a file mapping service
names to numbers, called \file{/etc/services}. It is described in
section~\ref{appl.services}.


It is worth noting that although both TCP and UDP connections rely on
ports, these numbers do not conflict. This means that TCP port 513, for
example, is different from UDP port 513. In fact, these ports serve as
access points for two different services, namely \keyword{rlogin} (TCP) and
\keyword{rwho} (UDP).


\index{network!port|)}

\subsection{The Socket Library}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.tcpip.sockets}
\index{network!programming interface}
\index{BSD socket library}
\index{socket}

In \unix{} operating systems, the software performing all the tasks and
protocols described above is usually part of the kernel, and so it is in
\linux. The programming interface most common in the \unix{} world is
the \emph{Berkeley Socket Library}. Its name derives from a popular
analogy that views ports as sockets, and connecting to a port as
plugging in. It provides the (\/\func{bind(2)}) call to specifiy a remote
host, a transport protocol, and a service which a program can connect or
listen to (using \func{connect(2)}, \func{listen(2)}, and
\func{accept(2)}).  The socket library is however somewhat more general,
in that it provides not only a class of TCP/IP-based sockets (the
\func{AF\_INET} sockets), but also a class that handles connections
local to the machine (the \func{AF\_UNIX} class). Some implementations
can also handle other classes as well, like the XNS (\emph{Xerox
Networking System}) protocol, or X.25.


In \linux{}, the socket library is part of the standard \file{libc}
C~library. Currently, it only supports \func{AF\_INET} and \func{AF\_UNIX}
sockets, but efforts are made to incorporate support for Novell's
networking protocols, so that eventually one or more socket classes for
these would be added.

\index{TCP/IP|)}


% \subsection{Internetworking}
% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \label{intro.tcpip.internetworking}
% In section~\ref{intro.tcpip.ip} we stated that it was IP's duty
% to link physically dissimilar networks to form an internet. But,
% of course, it would be rather limiting if this were the only way
% to link two networks. For example, assume a LAN that consists
% of several Ethernets. Linking them by just inserting a long piece
% of cable between the segments does not work because of the electrical
% specifications. On the other hand, inserting a gateway at each
% junction is prohibitive because of the delay introduced. Imagine
% some data of yours had to pass a dozen or so gateways just to
% travel a few hundred yards distance, being constantly wrapped and
% unwrapped by Ethernet drivers!
% 
% 
% A simple solution to this problem is the use of \emph{repeaters}.
% These are electrical devices used to connect two Ethernets, who
% do not perform any analysis of data passing through it, but only
% copy bits between them. Now traffic may float freely between these
% Ethernets. For example, at GMU's Mathematics Department, repeaters
% would be the device of choice if the professors' Ethernet had to be
% enlarged in order to give each professor his or her own X-terminal.
% 
% 
% Sadly, this does not work in all cases. For one, timing specifications
% require that a signal sent by one station on an Ethernet reaches
% any other station within a certain amount of time. This puts an upper
% boundary of four on the number of repeaters two stations may be apart.
% 
% 
% Another drawback of repeaters is that instead of at most a few dozen
% machines on one local segment, all machines from the linked segments
% compete for the right to transmit a frame. When segments A and B are
% linked by a repeater, all stations on segment A have to shut up when
% a station on segment B talks.
% 
% 
% Another solution is the use of \emph{bridges}. These are still
% Ethernet-specific devices, but instead of simple bit-shuffling,
% a bridge receives entire frames, analyzes the recipient's address, and
% only copies it to one of the adjacent segments when the recipient is known
% to be on that segment (or known to be reachable through this segment).
% A bridge does not suffer from the limitations of a repeater, because
% the single Ethernets remain separate entities, and frames are only copied
% to another segment if really needed. The drawback of bridges is that they
% need to be configured properly.
% 
% 
% As an example, a bridge might be useful to link the students' and
% professors' Ethernets at the Mathematics Department.
% 
% 
% Now, we have seen three types of equipment to link different
% physical networks: repeaters, bridges, and gateways (or routers),
% each at a different ``level'' of networking.
% Of course, one can also think of internetworking schemes that operate
% at still higher levels. For example, one could think of a program
% that accepts TCP connections for remote hosts, multiplexes
% them onto a serial line, with a similar program demultiplexing the whole
% on another machine and opening a separate TCP connection to the
% target host.\footnote{
%  In fact, there is a program for \linux{} that does roughly this.
%  This is the \prog{term(1)} program written by Michael O'Reilly,
%  \email{oreillym@tartarus.uwa.edu.au}.
% }
% 

\section{\linux{} Networking}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{Net-1}
\index{Net-2d}
\index{Net-2Debugged}
\index{Biro, Ross}
\index{Cox, Alan}
\index{Kempen, Fred van}

Being the result of a concerted effort of programmers around the world,
\linux{} wouldn't have been possible without the global network. So
it's not surprising that already in early stages of development, several
people started to work on providing it with network capabilities. A UUCP
implementation was running on \linux{} almost from the very beginning,
and work on TCP/IP-based networking started around autumn~1992, when
Ross Biro and others created what now has become known as Net-1.


After Ross quit active development in May 1993, Fred van~Kempen began to
work on a new implementation, rewriting major parts of the code. This
ongoing effort is known as Net-2. A first public release, Net-2d, was
made in Summer 1992 (as part of the 0.99.10 kernel), and has since been
maintained and expanded by several people, most notably Alan Cox, as
Net-2Debugged.  After heavy debugging and numerous improvements to the
code, he changed its name to Net-3 after \linux{} 1.0 was released.
This is the version of the networking code currently included in the
official kernel releases.


Net-3 offers device drivers for a wide variety of Ethernet boards, as
well as SLIP (for sending network traffic over serial lines), and PLIP
(for parallel lines).  With Net-3, \linux{} has a TCP/IP
implementation that behaves very well in a local area network
environment, showing uptimes that beat some of the commercial PC
\unices. Development currently moves toward the necessary stability to
reliably run it on Internet hosts.


Beside these facilities, there are several projects going on that will
enhance the versatility of \linux.  A driver for PPP (the
point-to-point protocol, another way to send network traffic over
serial lines), is at Beta stage currently, and an AX.25 driver for ham
radio is at Alpha stage. Alan Cox has also implemented a driver for
Novell's IPX protocol, but the effort for a complete networking suite
compatible with Novell's has been put on hold for the moment, because
of Novell's unwillingness to provide the necessary documentation.
Another very promising undertaking is \prog{samba}, a free
NetBIOS server for \unices{}, written by Andrew Tridgell.\footnote{
 NetBIOS is the protocol on which applications like \prog{lanmanager}
 and Windows for Workgroups are based.
}


\subsection{Different Streaks of Development}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{device driver interface|see {DDI}}
\index{Net-2e}
\index{Net-3}
\index{DDI}

In the meanwhile, Fred continued development, going on to Net-2e, which
features a much revised design of the networking layer.  At the time of
writing, Net-2e is still Beta software.  Most notable about Net-2e is
the incorporation of DDI, the \emph{Device Driver Interface}.  DDI offers
a uniform access and configuration method to all networking devices and
protocols.


\index{Urlichs, Matthias}
Yet another implemtation of TCP/IP networking comes from Matthias
Urlichs, who wrote an ISDN driver for \linux{} and FreeBSD. For this,
he integrated some of the BSD networking code in the \linux{} kernel.


For the foreseeable future, however, Net-3 seems to be here to stay.
Alan currently works on an implementation of the AX.25 protocol used
by ham radio amateurs. Doubtlessly, the yet to be developed ``module''
code for the kernel will also bring new impulses to the networking
code. Modules allow you to add drivers to the kernel at run time.


Although these different network implementations all strive to provide
the same service, there are major differences between them at the
kernel and device level.  Therefore, you will not be able to configure
a system running a Net-2e kernel with utilities from Net-2d or Net-3,
and vice versa. This only applies to commands that deal with kernel
internals rather closely; applications and common networking commands
such as \prog{rlogin} or \prog{telnet} run on either of them.


Nevertheless, all these different network version should not worry you.
Unless you are participating in active development, you will not have to
worry about which version of the TCP/IP code you run. The official
kernel releases will always be accompanied by a set of networking tools
that are compatible with the networking code present in the kernel.


\subsection{Where to Get the Code}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{obtaining the source code}
\index{FTP, location of \linux{} code}
\index{Net-2e}
\index{Net-3}
\index{Net-BSD}

The latest version of the \linux{} network code can be obtained by
anonymous FTP from various sites. The official FTP site for Net-3 is
\host{sunacm.swan.ac.uk}, mirrored by \host{sunsite.unc.edu} below
\file{system/Network/sunacm}.  The latest Net-2e patch kit and
binaries are available from \host{ftp.aris.com}.  Matthias Urlichs'
BSD-derived networking code can be gotten from \host{ftp.ira.uka.de}
in \file{/pub/system/linux/netbsd}.


The latest kernels can be found on \host{nic.funet.fi} in
\file{/pub/OS/Linux/PEOPLE/Linus}; \host{sunsite} and
\host{tsx-11.mit.edu} mirror this directory.


\section{Maintaining Your System}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{maintenance, system}
\index{system maintenance}

Throughout this book, we will mainly deal with installation and
configuration issues. Administration is, however, much more than that~---
after setting up a service, you have to keep it running, too.  For most of
them, only little attendance will be necessary, while some, like mail and
news, require that you perform routine tasks to keep your system
up-to-date.  We will discuss these tasks in later chapters.


The absolute minimum in maintenance is to check system and per-application
log files regularly for error conditions and unusual events. Commonly, you
will want to do this by writing a couple of administrative shell scripts
and run them from \prog{cron} periodically.  The source distribution of
some major applications, like \prog{smail} or C~News, contain such scripts.
You only have to tailor them to suit your needs and preferences.


The output from any of your \prog{cron} jobs should be mailed to an
administrative account. By default, many applications will send error
reports, usage statistics, or logfile summaries to the \user{root} account.
This only makes sense if you log in as \user{root} frequently; a much
better idea is to forward \user{root}'s mail to your personal account
setting up a mail alias as described in chapter~\ref{smail}.


However carefully you have configured your site, Murphy's law guarantees
that some problem \emph{will} surface eventually. Therefore, maintaining a
system also means being available for complaints. Usually, people expect
that the system administrator can at least be reached via email as
\email{root}, but there are also other addresses that are commonly used to
reach the person responsible for a specific aspect of maintenence. For
instance, complaints about a malfunctioning mail configuration will usually
be addressed \email{postmaster}; and problems with the news system may be
reported to \email{newsmaster} or \email{usenet}. Mail to
\email{hostmaster} should be redirected to the person in charge of the
host's basic network services, and the DNS name service if you run a name
server.


\subsection{System Security}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\index{system security}
\index{security!system}

Another very important aspect of system administration in a network
environment is protecting your system and users from intruders.
Carelessly managed systems offer malicious people many targets:  attacks
range from password guessing to Ethernet snooping, and the damage caused
may range from faked mail messages to data loss or violation of your
users' privacy. We will mention some particular problems when discussing
the context they may occur in, and some common defenses against them.


This section will discuss a few examples and basic techniques in dealing
with system security.  Of course, the topics covered can not treat all
security issues you may be faced with exhaustively; they merely serve to
illustrate the problems that may arise.  Therefore, reading a good book
on security is an absolute must, especially in a networked system.
Simon Garfinkel's ``Practical UNIX Security'' (see \cite{security}) is
highly recommendable.


System security starts with good system administration. This includes
checking the ownership and permissions of all vital files and directories,
monitoring use of privileged accounts, etc. The COPS program, for instance,
will check your file system and common configuration files for unusual
permissions or other anomalies. It is also wise to use a password suite
that enforces certain rules on the users' passwords that make them hard to
guess. The shadow password suite, for instance, requires a password to have
at least five letters, and contain both upper and lower case numbers and
digits.


\index{services!restricting access}
When making a service accessible to the network, make sure to give it
``least privilege,'' meaning that you don't permit it to do things that
aren't required for it to work as designed. For example, you should make
programs setuid to \user{root} or some other privileged account only
when they really need this. Also, if you want to use a service for only
a very limited application, don't hesitate to configure it as
restrictively as your special application allows. For instance, if you
want to allow diskless hosts to boot from your machine, you must provide
the TFTP (trivial file transfer service) so that they can download basic
configuration files from the \file{/boot} directory. However, when used
unrestricted, TFTP allows any user anywhere in the world to download any
world-readable file from your system. If this is not what you want,
why not restrict TFTP service to the \file{/boot} directory?\footnote{
 We will come back to this in chapter~\ref{appl}.
}


\index{access!restricting}
Along the same line of thought, you might want to restrict certain
services to users from certain hosts, say from your local network. 
In chapter~\ref{appl}, we introduce \prog{tcpd} which does this for
a variety of network applications.


Another important point is to avoid ``dangerous'' software. Of course,
any software you use can be dangerous, because software may have bugs
that clever people might exploit to gain access to your system. Things
like these happen, and there's no complete protection against this.
This problem affects free software and commercial products
alike.\footnote{
 There have been commercial \unices{} you have to pay lots of money for
 that came with a setuid-\user{root} shell script which allowed users to
 gain \user{root} privilege using a simple standard trick.
} However, programs that require special privilege are inherently more
dangerous than others, because any loophole can have drastic
consequences.\footnote{
 In 1988, the RTM worm brought much of the Internet to a grinding halt,
 partly by exploiting a gaping hole in some \prog{sendmail} programs.
 This hole has long been fixed since.
} If you install a setuid program for network purposes be doubly careful
that you don't miss anything from the documentation, so that you don't
create a security breach by accident.


\index{tripwire@\prog{tripwire}}
You can never rule out that your precautions might fail, regardless how
careful you have been. You should therefore make sure you detect
intruders early. Checking the system log files is a good starting point,
but the intruder is probably as clever, and will delete any obvious
traces he or she left. However, there are tools like
\prog{tripwire}\footnote{
  Written by Gene Kim and Gene Spafford.
} that allow you to check vital system files to see if their contents or
permissions have been changed.  \prog{tripwire} computes various strong
checksums over these files and stores them in a database.  During
subsequent runs, the checksums are re-computed and compared to the stored
ones to detect any modifications.



\section{Outlook on the Following Chapters}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{intro.outlook}

The next few chapters will deal with configuring \linux{} for
TCP/IP networking, and with running some major applications.
Before getting our hands dirty with file editing and the like,
we will examine IP a little closer in chapter~\ref{tcpip}. If you
already know about the way IP~routing works, and how address resolution
is performed, you might want to skip this chapter.


Chapter~\ref{hardware} deals with the very basic configuration issues,
such as building a kernel and setting up your Ethernet board.
The configuration of your serial ports is covered in a separate
chapter, because the discussion does not apply to TCP/IP networking
only, but is also relevant for UUCP.


Chapter~\ref{iface} helps you to set up your machine for TCP/IP
networking.  It contains installation hints for standalone hosts with
only loopback enabled, and hosts connected to an Ethernet.  It will also
introduce you to a few useful tools you can use to test and debug your
setup. The next chapter discusses how to configure hostname
resolution, and explains how to set up a name server.


This is followed by two chapters featuring the configuration and use of
SLIP and PPP, respectively. Chapter \ref{slip} explains how to establish
SLIP connections, and gives a detailed reference of \prog{dip}, a
tool that allows you to automate most of the necessary steps.
Chapter~\ref{ppp} covers PPP and \prog{pppd}, the PPP daemon you
need for this.


Chapter \ref{appl} gives a short introduction to setting up some of the
most important network applications, such as \prog{rlogin}, \prog{rcp},
etc, in chapter~\ref{appl}.  This also covers how services are managed
by the \prog{inetd} super, and how you may restrict certain
security-relevant services to a set of trusted hosts.


The next two chapters discuss NIS, the Network Information System, and
NFS, the Network File System.  NIS is a useful tool to distribute
administative information such as user passwords in a local area
network.  NFS allows you to share file systems between several hosts in
your network.


Chapter \ref{uucp} gives you an extensive introduction to the
administration of Taylor UUCP, a free implementation of the UUCP suite.


The remainder of the book is taken up by a detailed tour of electronic
mail and Usenet News. Chapter~\ref{mail} introduces you to the central
concepts of electronic mail, like what a mail address looks like, and
how the mail handling system manages to get your message to the
recipient.


Chapters~\ref{smail} and~\ref{sendmail} each cover the setup of
\prog{smail} and \prog{sendmail}, two mail transport agents you can use
for \linux.  This book explains both of them, because \prog{smail} is
easier to install for the beginner, while \prog{sendmail} is more
flexible.


Chapters~\ref{news} and~\ref{cnews} explain the way news are managed in
Usenet, and how you install and use C~news, a popular software package
for managing Usenet news. Chapter~\ref{nntp} briefly covers how to set
up an NNTP daemon to provide news reading access for your local network.
Chapter~\ref{newsreaders} finally shows you how to configure and
maintain various newsreaders.




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                             %%
%%              E N D   O F   C H A P T E R                    %%
%%                                                             %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

